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I. REAL PARTY IN INTEREST 

The name of the real party in interest for purposes of this appeal is Motorola, Inc., a 
Delaware corporation. 
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II. RELATED APPEALS AND INTERFERENCES 

There are no other appeals or interferences known to the Appellant, the Appellant's legal 
representative, or assignee which would directly affect or be directly affected by or having a 
bearing on the Board's decision in this pending appeal. 
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III. STATUS OF CLAIMS 

Claims 1-20 remain in the application. Claims 1-20 are being appealed. Claims 1-7, 10, 
1 1, 15-20 stand or fall together. 

In a final Office Action dated June 10, 2008, the Examiner rejected Claims 1-20 under 35 
U.S.C. 103(a) as being unpatentable over Jasen, et al. (US 2002/0019879) in view of Benveniste 
(US 2004/0196864). 
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IV. STATUS OF AMENDMENTS 

No amendments to the claims have been made subsequent to the Final Office Action 
mailed June 10,2008. 
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V. 



SUMMARY OF CLAIMED SUBJECT MATTER 



Although specification citations are inserted below in accordance with 37 C.F.R. § 41.37, 
these reference numerals and citations are merely examples of where support may be found in 
the specification for the terms used in this section of the brief There is no intention to in any 
way suggest that the terms of the claims are limited to the examples in the specification. 
Although, as demonstrated by the reference numerals and citations below, the claims are fully 
supported by the specification as required by law, it is improper under the law to read limitations 
from the specification into the claims. Pointing out specification support for the claim 
terminology, as is done here to comply with rule 41 .37, does not in any way limit the scope of 
the claims to those examples from which they find support. Nor does this exercise provide a 
mechanism for circumventing the law precluding reading limitations into the claims from the 
specification. In short, the reference numerals and specification citations are not to be construed 
as claim limitations or in any way used to limit the scope of the claims. 

The invention, as defined in independent Claim 1 and with reference to FIGs. 2 and 3, is 
a method for use by middleware (16) in a communication system comprising the steps of: 
enabling a group of behavior sets (220) for use by middleware (16) wherein the middleware 
provides an interface between at least one application (14) running on a first device and at least 
one network transport element (20) external to the first device, and wherein each behavior set in 
the group provides for at least one of a different set of routing rules and a different Quality of 
Service (230) for traffic sent between the at least one application and the at least one network 
transport element; operating (310, 330) in accordance with a first behavior set from said group; 
receiving at least one trigger (342, 344, 346) that indicates at least one of a condition of mission 
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criticality or a level of mission criticality for a situation that is external to the middleware, 
external to data routed to and from the middleware, and external to data associated with a user of 
the middleware; selecting (350) a second behavior set from said group based upon said at least 
one trigger; and operating (330) in accordance with said second behavior set. (Specification 
page 8, line 14 to page 9, line 10). 

The invention, as defined in independent Claim 18 and with reference to FIGs. 2 and 3, is 

a method for use in middleware (16) in a communication system comprising the steps of: 

enabling a group of behavior sets (220) to be predefined for use by a first middleware (16) 

wherein the first middleware provides an interface between at least one application (14) running 

on a first device and at least one network transport element (20) external to the first device, and 

wherein each behavior set in the group provides for at least one of a different set of routing rules 

and a different Quality of Service (230) for traffic sent between the at least one application and 

the at least one network transport element; operating (310, 330) in accordance with a first 

behavior set from said group; receiving at least one trigger (342, 344, 346) that indicates at least 

one of a condition of mission criticality or a level of mission criticality for a situation that is 

external to the middleware, external to data routed to and from the middleware, and external to 

data associated with a user of the middleware; selecting (350) a second behavior set from said 

group based upon said at least one trigger; notifying (320) a second middleware of the selecting 

of said second behavior set wherein the second middleware provides an interface between at 

least one application running on a second device and at least one network transport element 

external to the second device; and operating (330) in accordance with said second behavior set, 

said operating comprising implementing a set of routing rules and Quality of Service determined 

as a function of said second behavior set. (Specification page 11, line 22 to page 12, line 29). 
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The invention, as defined in independent Claim 1 and with reference to FIGs. 2 and 4, is 
middleware (16, 40) for mediating between at least one application (14, 52) and at least one 
communication network transport (20), said middleware comprising; an application interface 
(200, 400) to at least one application (14, 52) running on a device; a network interface (210, 410) 
to at least one network transport element external to the first device; a group of behavior sets, 
wherein each behavior set in the group provides for at least one of a different set of routing rules 
and a different Quality of Service (230, 430) for traffic sent between the at least one application 
and the at least one network transport element; and a behavior set selection function (240, 440) 
operative for causing said middleware to operate in accordance with a first behavior set from 
said group; receiving at least one trigger that indicates at least one of a condition of mission 
criticality or a level of mission criticality for a situation that is external to the middleware, 
external to data routed to and from the middleware, and external to data associated with a user of 
the middleware; selecting a second behavior set from said group based upon said at least one 
trigger; and causing said middleware to operate in accordance with said second behavior set. 
(Specification page 5, line 26 to page 7, line 3; and page 10, line 16, to page 11, line 27). 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

A. Whether Claims 1-20 are unpatentable under 35 U.S.C. 103(a) over Jasen, et al. 
(US 2002/0019879) in view of Benveniste (US 2004/0196864)? 
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VII. 
etal. 



ARGUMENT 

A. Claims 1-20 are rejected under 35 U.S.C. 103(a) as being unpatentable over Jasen, 
(US 2002/0019879) in view of Benveniste (US 2004/0196864). 



Claims 1-7, 10. 11. 15-20 

When looking at Appellant's claimed invention as a whole as recited in independent 
claims 1,18, and 19. Appellant's claimed invention is directed to operating in accordance with a 
first behavior set from a group of behavior sets, wherein each behavior set in the group provides 
for at least one of a different set of routing rules and a different Quality if Service for traffic sent 
between at least one application and at least one network transport element; receiving at least one 
trigger (wherein a trigger is defined as "a change in monitored conditions or parameters", 
specification at page 7, lines 8-9) that indicates at least one of a condition of mission criticality or 
a level of mission criticality for a situation that is external to the middleware, external to data 
routed to and from the middleware, and external to data associated with a user of the 
middleware; selecting a second behavior set from the group based on the at least one trigger; and 
operating in accordance with the second behavior set. Appellant respectfully submits that Jasen 
and Benveniste, individually or in combination do not teach or suggest all the claim limitations 
as set forth in the independent claims 1,18, and 19. For example, independent claims 1,18, and 
19 recite ". . .receiving at least one trigger that indicates at least one of a condition of mission 
criticality or a level of mission criticality for a situation that is external to the middleware, 
external to data routed to and from the middleware, and external to data associated with a user of 
the middleware. . . .", which is not taught or suggested by the combination of Jasen and 
Benveniste. 
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Jasen, et al. is directed to a method, system, and computer program product of prioritizing 
network services (Abstract). Such prioritization may comprise a better level of service, more 
timely system response and/or preferential treatment of traffic (paragraph 16, lines 3-6). 
Prioritization is controlled by defining modes and levels of prioritization typically based on 
criteria, such as the value of a transaction, the standing of a user, or the type of transaction 
(paragraph 16, lines 6-9). The modes of prioritization may comprise remapping TCP ports to 
which a communication is directed, remapping (including redirecting) uniform resource locators 
(URLs) and/or Internet Protocol (IP) addresses to which a communication is directed and/or 
tagging communications with quality of service (QoS) protocol information (paragraph 16, lines 
11-17). The levels of prioritization define the typc(s) of priority service offered to a user, such as 
timeliness of system response and preference of traffic treatment (paragraph 16, lines 17-19). 
Thus, through the use or prioritization, a network services provider can provide and control the 
network services to users of its services (paragraph 17, lines 1-3). 

A network traffic management (NTM) system comprises a set of client and server 
functionality (paragraph 18, lines 1-3). A network service provider that employs the NTM 
system determines whether the user of the NTM provider's network services is eligible for a 
NTM client and/or NTM prioritization (paragraph 18, lines 4-8). In a typical scenario, the user 
accesses a URL or IP address of the NTM provider through a Web browser, which access 
triggers the prioritization eligibility determination in the NTM server (paragraph 18, lines 9-1 1). 
If the user is not eligible, the NTM system allows for the provision of normal network services to 
the user, i.e., services without prioritization provided by the NTM system (paragraph 19, lines 1- 
4). If the user is eligible but does not have NTM client software installed, a NTM client is 
installed to the user's device (paragraph 20, lines 1-3). One or more electronic upgrade coupons 
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are also installed to the user's device, which are used in conjunction with the NTM system to 
facilitate the prioritization of the provision of network services to the user (paragraph 20, lines 7- 
9 and 11-13). If a NTM client is already installed on the user's device, the NTM system 
determines what package of information needs to be installed, such as one or more of, a full 
NTM client including one or more new coupons, an update to the existing NTM client, one or 
more new coupons, or an update to one or more existing coupons (paragraph 21, lines 1-2 and 5- 
10). 

Once the NTM client is installed, initialized, and operating, the user's network traffic or 
information about the traffic is routed through the NTM client to determine if the traffic should 
be provided prioritization or otherwise handled as normal network traffic (paragraph 22, lines 1- 
6). More particularly, the NTM client compares data associated with network traffic to coupon 
data in one or more coupons to determine whether a user's network traffic may receive NTM 
prioritization (paragraph 23, lines 1-4). Is a match is found and the coupon(s) is valid, the NTM 
client sends a message comprising information about the NTM client and/or coupons the NTM 
server announcing that a NTM prioritization session of network traffic is about to begin and to 
validate the NTM client and/or coupons (paragraph 24, lines 9). If the NTM client and/or 
coupon(s) are valid and a prioritization session can be started, the NTM server sends back a 
validation and acknowledgement to the NTM client, whereupon the NTM client then processes 
other coupon data in the existing, new or updated coupon(s) to determine the mode and level of 
prioritization offered during the session (paragraph 25, lines 1-4; and paragraph 26, lines 1-5). 

Benveniste is directed to an apparatus and methods for handling emergency message 
frames (e.g., "911" call frames, etc.) sent by a station in a wireless local-area network (Abstract). 
In an emergency call, the calling client in a wireless LAN will generate signaling frames to set 
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up a call (paragraph 9, lines 1-2). Signaling packets for call setup of a 91 1 call must be 
transmitted to the AP, on the wireless channel, quickly and reliably (paragraph 9, lines 3-5). To 
avoid delay in signaling frames, they are treating in a special way; e.g., by transmitting 911 
signaling frames with the same access priority as the AP (paragraph 11, lines 1-4). Once, the 
911 call is set up, voice data frames are generated as a constant periodic stream as voice is 
sampled periodically; and to ensure audible quality voice data, frames must arrive within a 
specified delay and with limited fitter on uplink and downlink transmissions (paragraph 14, lines 
1-7). The remainder of Benveniste described how the delay and fitter requirements can be met 
on the downlink and the uplink. 

The Office Action in item 3, pages 2-3 dated June 10, 2008 states that " Jasen , et al. 
discloses. . .receiving at least one trigger (see paragraph 24, where a trigger is considered 
applying a coupon) . . . [but] fails to disclose that the trigger indicates at least one of a condition of 
mission criticalitv or a level of mission criticalitv for a situation that is external to the 
middleware, external to data routed to and from the middleware, and external to data associated 
with a user of the middleware . .. In an analogous art Benveniste discloses a condition of mission 
criticality or a level of mission criticality for a situation that is external to the middleware, 
external to data routed to and from the middleware, and external to data associated with a user of 
the middleware (see paragraphs 1 1 and 14, describing how a condition for a mission critical 
situation (e.g., a 91 1 call) is treated with a higher quality of service; further implying that the 
mission critical situation is external (e.g., a fire external to the middleware, external to the data 
routed to and from the middleware, and external to the data associated with a user that caused 
someone to dial 911). Appellant disagrees with this argument. 
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Based on the summary above of Benveniste, this reference discloses in paragraphs 9, 1 1, 
and 14 how to quickly and reliably transmit 91 1 signaling packets generated by a calling client in 
order to set up a 91 1 call; and once the 91 1 call is set up how to ensure that the voice data frames 
sent during the 91 1 call arrive at their destination within a specified delay and with minimum 
fitter. Benveniste fails to disclose any type of middleware providing an interface between an 
application running on the device and a network transport element and fails to disclose a change 
in monitored conditions or parameters (i.e., trigger(s)) that indicate an emergency response 
condition external to the device, external to data transmitted to and from the device, and external 
to data associated with the user making the 91 1 call. At most Benveniste describes a user of a 
device making a 91 1 call, and the resulting 9 1 1 signaling and voice packets generated by the user 
device, i.e., the data routed from the user device, indicating that the packets should be given 
special treatment to ensure fast call set-up and clear delivery of voice during the 91 1 emergency 
response call. Thus, in Benveniste the type of packet determines how the packet is routed. 

Moreover, modifying Jasen, et al. with Benveniste would at most provide for one or more 
coupons in a user device that included data directed to an emergency condition. Accordingly, 
when the 91 1 signaling and voice packets generated in Benveniste are sent through the NTM 
client of Jasen, et al. and compared to the relevant coupons, a match would cause the NTM client 
to signal an NTM session for the 9 1 1 signaling and voice packets so that these packets would be 
given NTM priority treatment. Thus, based on the combined teachings of Jasen, et al. and 
Benveniste, the type of data included in the packet would determine how the packet is routed or 
the priority to be given to the packet. By contrast, claims 1,18, and 19 recite " receiving at least 
one trigger [i.e., a change in monitored conditions or parameters] that indicates at least one of a 
condition of mission criticality or a level of mission criticality for a situation that is external to 
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the middleware, external to data routed to and from the middleware, and external to data 
associated with a user of the middleware " and this change in monitored condition being used to 
select a behavior set to provide a set of routing rules and/or a QoS for the traffic being sent, 
which is not taught or suggested by Jasen or Benveniste, individually or in combination. 

In view of the foregoing, Appellant submits that all of the limitations of claims 1,18, and 
19 are not taught or suggested in the teachings of Jasen and Benveniste either individually or in 
combination, and therefore the rejection of claims 1,18, and 19 under 35 USC 103(a) should be 
withdrawn. Appellant requests that claims 1,18, and 19 now be passed to allowance. 

Dependent claims 2-7, 10, 11, 15-17, and 20 depend from, and include all the limitations 
of independent claim 1 . Therefore, Appellant respectfully requests the reconsideration of 
dependent claims 2-7, 10, 11, 15-17, and 20 and requests withdrawal of the rejection of these 
claims. Appellant requests that claims 2-7, 10, 11, 15-17, and 20 now be passed to allowance. 

Claim 8 

Appellant disagrees with the statement in item 3, page 5 of the Office Action dated June 
10, 2008 that "As per claim 8, Jasen further discloses that the at least one trigger is at least one of 
a remote trigger and an external trigger (see paragraph 23)." The Office Action in item 3, page 3 
analogized a trigger to applying a coupon. The application of a coupon occurs internal to a client 
device {see, e.g., paragraph 23, the NTM client matches data associated with the network traffic 
to coupon data), and therefore cannot read on the limitations of claim 8 of a "remote trigger" or 
an "external trigger". 

In view of the foregoing, Appellant submits that all of the limitations of claim 8 are not 
taught or suggested in the teachings of Jasen and Benveniste either individually or in 
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combination, and therefore the rejection of claim 8 under 35 USC 103(a) should be withdrawn. 
Appellant requests that claim 8 now be passed to allowance. 

Claim 9 

Appellant disagrees with the statement in item 3, page 5 of the Office Action dated June 
10, 2008 that 'As per claim 9, Jasen further discloses examining state information, and wherein 
said second behavior set is selected based upon said state information (see paragraph 23)." 
Appellant has reviewed the reference including paragraph 23 and cannot locate examining state 
information and selecting a second behavior set based on state information. Paragraph 23, by 
contrast, discloses the NTM client examining network traffic in light of coupon data in one or 
more coupons to determine whether the network traffic should receive NTM prioritization. 
Appellant requests that specific line numbers be provided and specific identification be provided 
of the teachings that can be analogized to the limitations in claim 9 or that the rejection be 
withdrawn. Appellant requests that claim 9 now be passed to allowance. 

Claim 12 

Appellant disagrees with the statement in item 3, page 5 of the Office Action dated June 
10, 2008 that 'As per claim 12, Jasen further discloses that determination of said first condition 
is made external to said middleware and communicated to said middleware via said at least one 
trigger (see paragraph 23)." Paragraph 23, by contrast, discloses the NTM client examining 
network traffic in light of coupon data in one or more coupons to determine whether the network 
traffic should receive NTM prioritization. This comparing occurs internal to the NTM client 
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software within the user device. Therefore, Jasen fails to read on "determination of said first 
condition is made external to said middleware ", recited in claim 12. 

In view of the foregoing, Appellant submits that all of the limitations of claim 12 are not 
taught or suggested in the teachings of Jasen and Benveniste either individually or in 
combination, and therefore the rejection of claim 12 under 35 USC 103(a) should be withdrawn. 
Appellant requests that claim 12 now be passed to allowance. 

Claim 13 

Appellant disagrees with the statement in item 3, page 5 of the Office Action dated June 
10, 2008 that "As per claim 13, Jasen further discloses that determination of said first condition 
is made by a second middleware that provides an interface between at least one application 
running on a second device and at least one network transport element external to the second 
device (see paragraph 23)." Paragraph 23, by contrast, discloses the NTM client examining 
network traffic in light of coupon data in one or more coupons to determine whether the network 
traffic should receive NTM prioritization. This comparing occurs internal to an NTM client 
software within one user device. Therefore, Jasen fails to read on "determination of said first 
condition is made by a second middleware ...running on a second device '", recited in claim 13. 

In view of the foregoing, Appellant submits that all of the limitations of claim 13 are not 
taught or suggested in the teachings of Jasen and Benveniste either individually or in 
combination, and therefore the rejection of claim 13 under 35 USC 103(a) should be withdrawn. 
Appellant requests that claim 13 now be passed to allowance. 
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Claim 14 

Appellant disagrees with the statement in item 3, page 5 of the Office Action dated June 
10, 2008 that "As per claim 14, Jasen further discloses that determination of said first condition 
is made manually (see paragraph 47)." Paragraph 47, by contrast, describes a method for 
installing the NTM client (i.e., a verbose install) that provides the user of the device with an 
option of rejecting the installation of the NTM client. Therefore, Jasen fails to read on 
" determination of said first condition is made manually", recited in claim 14. 

In view of the foregoing, Appellant submits that all of the limitations of claim 14 are not 
taught or suggested in the teachings of Jasen and Benveniste either individually or in 
combination, and therefore the rejection of claim 14 under 35 USC 103(a) should be withdrawn. 
Appellant requests that claim 14 now be passed to allowance. 

Conclusion 

Appellant respectfully requests that a timely Notice of Allowance be issued in this case. 

Such action is earnestly solicited by the Appellant. Should the Examiner have any questions, 

comments, or suggestions, the Examiner is invited to contact the Appellant's attorney or agent at 

the telephone number indicated below. 

Please charge any fees that may be due to Deposit Account 5021 17, Motorola, Inc. 

Respectfully submitted, 

Bekiares, et al. 

by: /Valerie M. Davis/ 
Valerie M. Davis 
Attorney for Appellant 
Registration No. 50,203 
Phone: (847)576-6733 
Fax: (847)576-0721 



VIII. CLAIMS APPENDIX 

1 . (Previously Presented) A method for use by middleware in a communication system 
comprising the steps of: 

enabling a group of behavior sets for use by middleware wherein the middleware 
provides an interface between at least one application running on a first device and at least one 
network transport element external to the first device, and wherein each behavior set in the group 
provides for at least one of a different set of routing rules and a different Quality of Service for 
traffic sent between the at least one application and the at least one network transport element; 

operating in accordance with a first behavior set from said group; 

receiving at least one trigger that indicates at least one of a condition of mission 
criticality or a level of mission criticality for a situation that is external to the middleware, 
external to data routed to and from the middleware, and external to data associated with a user of 
the middleware; 

selecting a second behavior set from said group based upon said at least one trigger; and 
operating in accordance with said second behavior set. 

2. (Previously Presented) The method of Claim 1 further comprising the step of notifying a 
second middleware of the selecting of said second behavior set, wherein the second middleware 
provides an interface between at least one application running on a second device and at least 
one network transport element external to the second device. 
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3. (Previously Presented) The method of Claim 1, wherein said at least one trigger is at least 
one of: 

a light bar activation; 

a light bar deactivation; 

a change in the time of day; 

the speed of a vehicle; 

location information; 

an emergency bar activation; 

an emergency bar deactivation; 

an emergency button activation; 

an emergency button deactivation; 

a siren activation; 

a siren deactivation; 

a dispatch warning; 

a change in dispatch status; 

a change in incident status; and 

a change in situational status. 

4. (Original) The method of Claim 1, wherein said middleware is a middleware client. 

5. (Original) The method of Claim 1, wherein said middleware is a middleware server. 
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6. (Original) The method of Claim 1, wherein said step of operating comprises 
implementing a set of routing rules and Quality of Service determined as a function of said 
second behavior set. 

7. (Original) The method of Claim 1 , wherein said first behavior set is a default behavior 
set. 

8. (Original) The method of Claim 1, wherein said at least one trigger is at least one of a 
remote trigger and an external trigger. 

9. (Original) The method of Claim 1 further comprising the step of examining state 
information, and wherein said second behavior set is selected based upon said state information. 

10. (Original) The method of Claim 1, wherein said second behavior set is selected based 
upon a determination of a first condition. 

1 1 . (Previously Presented) The method of Claim 1 0, wherein said first condition is the at 
least one of the condition of mission criticality or the level of mission criticality. 

12. (Original) The method of Claim 10, wherein said determination of said first condition is 
made external to said middleware and communicated to said middleware via said at least one 
trigger. 
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13. (Previously Presented) The method of Claim 12, wherein said determination of said first 
condition is made by a second middleware that provides an interface between at least one 
application running on a second device and at least one network transport element external to the 
second device. 

14. (Original) The method of Claim 12, wherein said determination of said first condition is 
made manually. 

15. (Original) The method of Claim 1 0, wherein said determination of said first condition is 
made internal to said middleware based on said at least one trigger. 

16. (Original) The method of Claim 1, wherein at least one of the behavior sets in said group 
is predefined. 

17. (Original) The method of Claim 1, wherein at least one of the behavior sets in said group 
is dynamically determined. 
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18. (Previously Presented) A method for use in middleware in a communication system 
comprising the steps of: 

enabling a group of behavior sets to be predefined for use by a first middleware wherein 
the first middleware provides an interface between at least one application running on a first 
device and at least one network transport element external to the first device, and wherein each 
behavior set in the group provides for at least one of a different set of routing rules and a 
different Quality of Service for traffic sent between the at least one application and the at least 
one network transport element; 

operating in accordance with a first behavior set from said group; 

receiving at least one trigger that indicates at least one of a condition of mission 
criticality or a level of mission criticality for a situation that is external to the middleware, 
external to data routed to and from the middleware, and external to data associated with a user of 
the middleware; 

selecting a second behavior set from said group based upon said at least one trigger; 

notifying a second middleware of the selecting of said second behavior set wherein the 
second middleware provides an interface between at least one application running on a second 
device and at least one network transport element external to the second device; and 

operating in accordance with said second behavior set, said operating comprising 
implementing a set of routing rules and Quality of Service determined as a function of said 
second behavior set. 
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19. (Previously Presented) Middleware for mediating between at least one application and at 
least one communication network transport, said middleware comprising; 

an application interface to at least one application running on a device; 

a network interface to at least one network transport element external to the first device; 

a group of behavior sets, wherein each behavior set in the group provides for at least one 
of a different set of routing rules and a different Quality of Service for traffic sent between the at 
least one application and the at least one network transport element; and 

a behavior set selection function operative for causing said middleware to operate in 
accordance with a first behavior set from said group; receiving at least one trigger that indicates 
at least one of a condition of mission criticality or a level of mission criticality for a situation that 
is external to the middleware, external to data routed to and from the middleware, and external to 
data associated with a user of the middleware; selecting a second behavior set from said group 
based upon said at least one trigger; and 

causing said middleware to operate in accordance with said second behavior set. 

20. (Original) A system comprising at least one middleware server and at least one 
middleware client, each operative in accordance with the method of Claim 1 . 
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IX. EVIDENCE APPENDIX 

No evidence has been submitted pursuant to 37 C.F.R. §§ 1.130, 1.131, or 1.132, entered 
by the examiner and relied upon by the appellant in the appeal, or relied upon by the examiner as 
to grounds of rejection to be reviewed on appeal. 
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X. RELATED PROCEEDINGS APPENDIX 

No decisions have been rendered by a court of the Board in any proceeding identified 
pursuant to paragraph (c)(1)(h) of 37 CE.R. § 41.37. 
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